Šiandien mašininis vertimas yra toks geras, kad daugeliu atvejų jo neįmanoma atskirti nuo žmogaus atlikto vertimo. Vertimo paslaugos užtikrina sklandų, idiominį vertimą, atsižvelgiantį į kalbos stilių. Tačiau kai verčiate DPP duomenų rinkinį, staiga „rear lock fiber closure“ tampa „užpakalinio užrakto pluošto uždarymas“.
Problema - specializuota terminologija. Čia paaiškinsime, kodėl produktų duomenų negalima traktuoti kaip romanų ir kokias priemones siūlo „Transpareo“, kad jūsų 39 kalbų versijos išliktų suprantamos.
Pagrindinė problema: vienas žodis, kelios reikšmės
„Seal“ lauko striukės DPP duomenų rinkinyje: sandarinimas. „Seal“ laboratorijoje: ruonis arba sandariklis, priklausomai nuo konteksto. „Seal“ techninės priežiūros protokole: tam tikromis aplinkybėmis - antspaudas.
Bendrasis vertimo modelis renkasi remdamasis statistiniu kontekstu. Tai veikia sklandžiai tekste - romanas suteikia gausų kontekstą. Duomenų laukelyje „primary_closure: seal“ konteksto beveik nėra. Modelis spėja.
Dėl to atsiranda subtilios klaidos. Ne tokios dramatiškos kaip „užpakalinė užraktinė pluošto uždarymo detalė“, bet turinčios rimtų pasekmių: komponentas, kuris vokiečių kalboje vadinamas „Dichtung“, italų DPP staiga vadinamas „sigillo“, o ne „guarnizione“. Pirkėjas nebegali rasti tos atsarginės dalies.
Ką šiandien siūlo „Transpareo“
Mūsų vertimo sistema automatiškai perkelia kiekvieną naują turinį į visas aktyvias kalbas. Ją apibūdina keturios savybės:
-
„Markdown“ ir kintamųjų išsaugojimas: prieš vertimą išskiriami vietos laikikliai, pvz.,
<a href="/lt/užsiregistruoti">Pro-Mitgliedschaft</a>, ir „Markdown“ struktūros, verčiamas tik tekstas, o po to struktūros vėl įterpiamos nepakeistos. Taip nuorodos, formos ir išdėstymas išlieka nuoseklūs visose kalbose. - Centralizuoti vertimų įrašai: vertimai saugomi ne pačiame duomenų įraše, o bendrame sluoksnyje. Keletas duomenų įrašų su tuo pačiu originalaus teksto turiniu dalijasi vienu vertimu. Tai leidžia sutaupyti vertimo išlaidų ir automatiškai suvienodina terminus visame duomenų modelyje.
- Automatinis pakartotinis vertimas pakeitus tekstą: jei originalus tekstas pakeičiamas, vertimai visomis kalbomis generuojami iš naujo. Pataisa vokiečių kalba - 38 kitos kalbinės versijos atnaujinamos automatiškai.
- Žymėjimai kiekvienam įrašui: turinį galima išskirti iš automatinio apdorojimo arba užfiksuoti esamus vertimus - pavyzdžiui, tarptautinių produktų pavadinimų atveju arba atliekant rankinius pataisymus.
Kur klientas papildo apdorojimą
Automatinis vertimas daugeliu atvejų pateikia teisingus rezultatus aprašomiesiems tekstams, rinkodaros tekstams ir priežiūros instrukcijoms. Tačiau esant kritinei specializuotai terminijai - pavyzdžiui, „seal“/„guarnizione“ - lieka nedidelis klaidų skaičius, kurias turi ištaisyti kliento administratorius.
Čia administratorius turi tris galimybes:
- Rankinis perrašymas pagal kalbą ir raktinį žodį: kiekvieną vertimo įrašą galima atidaryti programos valdytoje ir pritaikyti pagal kalbą. Pažymėjus „Įtvirtinti“, šis rankinis vertimas išliks ir per kitą automatinį apdorojimo ciklą.
- Žodyno importavimas: esamą terminiją iš vertimo įrankių ar PDF žodynų galima importuoti CSV formatu ir taip tiesiogiai sukurti vertimo įrašus.
- Pataisymai pagal kalbą veikimo metu: Italijos pardavimo skyrius pastebi klaidą, ją ištaiso programų valdytoje - pataisa įsigalioja iš karto, o likusios vertimų versijos lieka nepakitusios.
ES kalbų realybė
24 ES oficialiosios kalbos - skamba daug. Praktikoje jos suskirstytos į tris grupes:
- Pagrindinės rinkos: DE, EN, FR, IT, ES, NL - čia kiekvienas vartotojas tikisi tobulumo
- Svarbios rinkos: PT, PL, SV, DA, FI - geras lygis, kartais pastebimas mašininis vertimas
- Retos kalbos: MT, GA, ET, LV, LT - kartais tenka pateikti DPP maltiečių kalba, nors nė vienas galutinis vartotojas Maltoje jo neskaito. Vis dėlto tai privaloma.
Šis reikalavimas nėra pasirinktinis. ESPR reikalauja, kad DPP turinys būtų pateiktas tos valstybės narės kalba, kurioje produktas parduodamas. Taigi, kas aptarnauja 27 valstybes, turi atsižvelgti į 24 kalbas (kai kurios valstybės dalijasi tomis pačiomis kalbomis).
Kodėl reikalingas centralizuotas lokalizavimo lygmuo
Dauguma platformų saugo vertimus kaip papildomus duomenų įrašo laukelius: description_de, description_en, … 39 laukeliai vienam verčiamam atributui. Skamba paprastai, tačiau turi tris trūkumus:
- Dvigubai saugomas tekstas. Du produktai su ta pačia medžiagos nuoroda sukuria 39 + 39 vertimus, o ne vieną 39 vertimą
- Sunku pritaikyti didesniam mastui. 40-osios kalbos pridėjimas reiškia: schemos migraciją per visus verčiamus modelius
- Pataisas sunku taikyti visuotinai. Jei „guarnizione“ būtų pataisyta visur, reikėtų atskirai redaguoti visus duomenų įrašus
Šią problemą išsprendžia atskiras vertimo sluoksnis: vienas įrašas, daug nuorodų. Viena pataisa, nauda visiems duomenų įrašams.
Ko mums dar trūksta
Klientui pritaikyta terminologijos duomenų bazė su automatiniu pasiūlymų atpažinimu yra įtraukta į plėtros planus, tačiau šiuo metu dar nėra pateikta. Kas pradeda dirbti šiandien, gali daug pasiekti naudodamasis esamais įrankiais: rankinis perrašymas, žodynų importavimas ir žymėjimas „išsaugoti“ padengia dažniausius naudojimo atvejus.
Manome, kad mašinos turėtų atlikti didžiąją dalį darbo, o žmonės turėtų įsikišti tik ten, kur tai tikrai būtina. Kol automatinis terminų atpažinimas nebus prieinamas, rankinis valdymas yra skaidrus - ir tai sąžiningiau nei pažadas, kurio neįmanoma išpildyti.